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Abstract 


This text documents the current usage of P-Charge-Info, an existing 
Session Initiation Protocol (SIP) private header field (P-Header) 
used to convey billing information about the party to be charged. 
This P-Header is currently used in production by several equipment 
vendors and carriers and has been in use since at least 2007. This 
document details the registration of this header field with IANA. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are candidates for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8496. 
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ces 


Overview 


In certain network configurations, several network entities hav 

found it useful to decouple the identity of the caller (what is 
normally thought of as "Caller ID") from the identity/number used for 
billing purposes. This document records the current usage of 
P-Charge-Info, a private SIP header field, to provide simple billing 
information and details the registration of this header field with 
IANA as required by Section 4 of [RFC5727]. 


In a typical configuration, the identity of the caller, commonly 
referred to as "Caller ID" by end users, is derived from one of the 
following SIP header fields: 


o P-Asserted-Identity 
o From (in the absence of P-Asserted-Identity) 


(NOTE: Some service providers have also used the Remote-Party-ID 
header field, but this was never standardized and was replaced by 
P-Asserted-Identity in [RFC3325].) 


This identity/number is typically presented to the receiving user 
agent (UA), where it is usually displayed for the end user. It is 
also typically used for billing purposes by the network entities 
involved in carrying the session. 


However, in some network configurations, the "Caller ID" presented to 
the receiving UA may be different from the number to be used for 
billing purposes. 


In this case, there exists a need for a way to pass an additional 
billing identifier that can be used between network entities in order 
to correctly bill for services. 


Several carriers, application providers, and equipment providers have 
been using the P-Charge-Info header field since at least 2007 as a 
simple mechanism to exchange this billing identifier. 


This document specifies the use of the P-Charge-Info header field in 
INVITE requests. The header field might be useful in other SIP 
messages, but such use is beyond the scope of this document. 
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2% 


Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", “NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


The key words describe requirements needed to interoperate with 
existing usage. 


Purpose of This Document 


This document has been prepared to document the existing deployed 
usage of the P-Charge-Info header field and to comply with Section 4 
of [RFC5727] in registering this header field with IANA. It is noted 
that RFC 5727 specifically deprecates new usage of "P-" header 
fields, but P-Charge-Info has been in deployment since before 2007 
and predates RFC 5727. Given this, the authors believe that 
P-Charge-Info is a "grandfathered case" per Section 4 of RFC 5727. 


Use Cases 


The simplest use case for P-Charge-Info is an enterprise environment 
where each SIP endpoint has a direct number that is passed by the 
enterprise SIP proxy across to a SIP proxy at a SIP service provider 
who provides connectivity to the Public Switched Telephone Network 
(PSTN). Rather than cause the SIP service provider to have to track 
each individual direct number for billing purposes, the enterprise 
SIP proxy sends, in the P-Charge-Info header field, a single billing 
identifier that the SIP service provider uses for billing purposes. 


As another example, a hosted telephony provider or hosted voice- 
application provider may have a large SIP network with customers who 
are distributed over a very large geographic area and use local- 
market PSTN numbers, although the network has only a very few actual 
PSTN interconnection points. 


The customers may all have local phone numbers, yet outgoing calls 
are actually routed across a SIP network and out specific PSTN 
gateways or across specific SIP connections to other SIP service 
providers. The hosted provider may want to pass a billing identifier 
to its SIP service providers either for the purpose of simplicity in 
billing or to obtain better rates from the SIP service providers. 
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5. The P-Charge-Info Header 
5.1. Applicability Statement for the P-Charge-Info Header Field 
The P-Charge-Info header field is applicable within a single private 


administrative domain or between different administrative domains 
where there is a trust relationship between the domains. 


5.2. Usage of the P-Charge-Info Header Field 


The P-Charge-Info header field is used to convey information about 
the identity of the party to be charged. The P-Charge-Info header 
field is typically inserted into a SIP request, usually an INVITE, by 
one of the following: 


o the SIP proxy on the originating network; 
o a PSTN gateway acting as a SIP UA; or 


o an application server generating billing information. 


P-Charge-Info is to be used by the SIP entity that provides billing 
services for a session. This could be an entity that is generating 
billing records or another entity interacting with it. Upon receipt 
of an INVITE request with the P-Charge-Info header field, such an 
entity MAY use the value present in P-Charge-Info as indicating the 
party responsible for the charges associated with the session. This 
decision, for example, could be based on local policy. 


5.2.1. Procedures at the UA 


The P-Charge-Info header field may be inserted by PSTN gateways or 
application servers acting as a SIP UA. 


The P-Charge-Info header field is ignored by an end-user UA and 
should not normally be received by such a UA. It MUST NOT be sent to 
an end-user UA, as this would provide information to the UA about the 
party to be charged; providing such information may cause security- 
related issues; for example, calling-party information would be known 
by the UA for an otherwise anonymous call. A UA SHOULD ignore it if 
it receives this header. Similarly, an end-user UA originating a SIP 
message SHOULD NOT insert this header field. 


A PSTN gateway or application server acting as a UA MAY use the 
content of the P-Charge-Info header field present in an INVITE 
request it received as the identity to be charged for the session for 
billing-related procedures, e.g., in a billing record or during 
interaction with another entity generating billing records. A PSTN 
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gateway or application server acting as a UA MAY use the content of 
the P-Charge-Info header field to populate information about the 
identity of the party to charge in another type of signaling, such as 
ISDN User Part (ISUP). 


5.2.2. Procedures at the Proxy 


A SIP proxy that supports this extension and receives a request, 
typically a SIP INVITE, MAY insert a P-Charge-Info header field. The 
contents of the inserted header field may be decided based on local 
policy or by querying an external entity to determine the identity of 
the party to be charged. 


When a proxy receives an INVITE request, it MAY use the content of 
the P-Charge-Info header field contained in the request for billing- 
related procedures, e.g., in a billing record or during interaction 
with another entity that is generating billing records. 


A SIP proxy that does not support this extension will pass any 
received P-Charge-Info header field unmodified, in compliance with 
RFC 3261. 


A proxy supporting this extension MUST remove the P-Charge-Info 
header field before sending a request to a UA that is not acting as a 
PSTN gateway or appropriate application server, if the role of the UA 
is known. 


5.3. Use-Case Example 
The content of the P-Charge-Info header field is typically just a 
SIP/tel URI used as a billing indicator. An example could be as 


simple as one of: 


P-Charge-Info: <sip:+14075550134@example.net; user=phone> 


P-Charge-Info: <sip:+12345550167@example.com> 
P-Charge-Info: <sips:1234@example.com> 


P-Charge-Info: <tel:+14075551234> 


Any other applicable SIP URI could be used. 
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6. 


7 


8. 


8. 


Formal Syntax 


This RFC contains the definition of one or more SIP header fields 
that allow choosing between addr-spec and name-addr when constructing 
header-field values. [RFC8217] prohibits the use of addr-spec if its 
value would contain a comma, semicolon, or question mark. 


The private header field specified here is described in both prose 
and an augmented Backus-Naur Form (BNF) defined in [RFC5234]. 
Further, several BNF definitions are inherited from SIP and are not 
repeated here. Implementors need to be familiar with the notation 
and contents of [RFC3261] and [RFC5234] to understand this document. 


The syntax of the P-Charge-Info header field is described as follows: 


P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec) 
; name-addr and addr-spec are specified in RFC 3261 


The SIP URI contained in the name-addr/addr-spec is the billing 
indicator that is passed between the parties. 


IANA Considerations 


This specification registers a new proprietary SIP header field 
according to the procedures defined in [RFC5727]. 


-l. Header Field 


The P-Charge-Info private header field has been registered in the 
"Header Fields" subregistry of the "Session Initiation Protocol (SIP) 
Parameters" registry as follows: 

Header Field Name: P-Charge-Info 

Compact Form: none 

Reference: RFC 8496 
Security Considerations 

1. Trust Relationship 

Given that the information contained in the P-Charge-Info header 


field will be used for billing purposes, the proxies and other SIP 
entities that share this information MUST have a trust relationship. 
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8. 


9. 


9. 


If an untrusted entity were inserted between the trusted entities, it 
could potentially interfere with the billing records for the call. 

If the SIP connections are not made over a private network, a 
mechanism for securing the confidentiality and integrity of the SIP 
connection MUST be used to protect the information. One such 
mechanism could be TLS encryption of the SIP signaling stream. 


-2. Untrusted Peers 


-2.1. Ingress from Untrusted Peers 


If the P-Charge-Info header field was accepted by a SIP entity from 
an untrusted peer, there is the potential for fraud if the untrusted 
entity sent incorrect information, either inadvertently or 
maliciously. 


Therefore, a SIP entity MUST remove and ignore the P-Charge-Info 
header field when it is received from an untrusted entity. 


2.2. Egress to Untrusted Peers 


If the P-Charge-Info header field was sent by a SIP entity to an 
untrusted peer, there is potential for exposure of network 
information that is internal to a trust domain. For instance, the 
untrusted entity may learn the identities of public SIP proxies used 
within the trust domain, which could then potentially be directly 
attacked. 


If an implementation does not strip P-Charge-Info from the message 
where specified in this document, it introduces serious privacy 
risks. Examples include revealing third-party billing relationships 
that might be sensitive, as well as unmasking the identity of callers 
who wish to remain anonymous. Depending on circumstances, the latter 
case may result in unwanted harassment and even physical harm to the 
calling party. 


Therefore, a SIP entity MUST remove the P-Charge-Info header field 
when it is sent to an untrusted entity. 
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Appendix A. Alternatives 


A. 


A. 


Fx 


2 


P-Charging-Vector 


P-Charging-Vector is defined in Section 4.6 of [RFC7315] and used by 
the 3GPP to carry information related to the charging of a session. 
There are, however, some differences in the semantics associated with 
P-Charging-Vector and P-Charge-Info. P-Charging-Vector is mainly 
used to carry information for correlation of multiple charging 
records generated for a single session. On the other hand, 
P-Charge-Info is used to convey information about the party to be 
billed for a call. Furthermore, P-Charging-Vector has a mandatory 
icid-value parameter that is a globally unique value to identify the 
session for which the charging information is generated. Such a 
globally unique identifier is not necessary when carrying information 
about the user to be billed when it is attached to the corresponding 
session-related signaling. 


P-DCS-Billing-Info 


P-DCS-Billing-Info is defined in Section 7 of [RFC5503] and used for 


passing billing information between trusted entities in the 
PacketCable Distributed Call Signaling Architecture. For many 
billing situations, particularly the very large-scale residential 


telephone networks for which this header field is designed, 
P-DCS-Billing-Info is an excellent solution. However, this ability 
to address a range of situations adds complexity. According to RFC 
5503, the following information is mandatory to include in each use 
of the P-DCS-Billing-Info header field: 


o Billing-Correlation-ID, a globally unique identifier 


o Financial-Entity-ID 


o RKS-Group-ID (record-keeping server) 


The P-DCS-Billing-Info header field may also include a variety of 
additional parameters. 


While this may work well in many billing scenarios, there are other 
billing scenarios that do not need this level of complexity. In 
those simpler scenarios, all that is needed is a number to use for 
billing. P-Charge-Info provides this simple solution for simple 
billing scenarios. 


Additionally, according to Section 7.3 of RFC 5503, it is mandatory 
for a UA to create a Billing-Correlation-ID and insert this into the 
P-DCS-Billing-Info header field (along with the other required 
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information) 


P-Charge-Info 


sent in the initial SIP INVITE. 


for the residential-telephone-servic 
header field is designed. 


In contrast, 


October 2018 


This again makes sense 
nvironment for which this 
P-Charge-Info is designed to 


be used among proxies and not at all by normal user agents. 


(P-Charge-Info may, 
PSTN gateways.) 


A.3. P-Asserted-Identity 


though, be used by user agents associated with 


Early reviewers of this document asked why the P-Asserted-Identity 


header field documented in [RFC3325] 
in the use-cas xample above, 


instance, th 
SIP-to-PSTN interconnect point. 


could not be used. 
P-Asserted-Identity is used to 
indicate the identity of the calling party. 
requirement is to provide an additional 


As mentioned 


in this 
identity of the 


However, 


It would be typical to find both P-Asserted-Identity and 


P-Charge-Info used in a SIP exchange. 


P-Asserted-Identity would be 


used to provide the caller identity that would be displayed to the 


end user as "Caller ID", 


while P-Charge-Info would provide the 


billing identifier used for the billing associated with the call. 
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